<timeDelayAndSync>

	Need to unify the interfaces which have similar functions about time, delays, and synchronization.
	Maybe also include functions about measuring progress.

	</functionsThatMeasureProgress>
		
		public int framesNowWant(); //in AudStream
		public double wantMoreProgress(); //in Task
		
		public int framesNowNeed(); //in AudStream
		public double needMoreProgress(); //in Task
		
		public int framesNow(double importance); //in AudStream
		
		public double needMaxWait(); //in Task
		
		public double wantMaxWait(); //in Task
		
		
		
		public double getFrameRate(); //in AudStreamInfo
		
		
		
		public double totalProgress(); //in Task
		
		
	</functionsThatMeasureProgress>
	
	<functionsThatIncreaseProgress>
		
		public void run(double tryToDoThisMuchProgress) throws Exception; //in Task
		
		public void audStream(double d[], int offset, int len) throws Exception; //in AudStream		
		public void run(int startIndex, double d[]); //in FloatFunc
		
	</functionsThatIncreaseProgress>
	
	<interfaces>
		AudStreamInfo
		AudStream
		Task
		FloatFunc
	</interfaces>
	
	Constant target speed
		public double getFrameRate(); //in AudStreamInfo
		
	Total position
		public double totalProgress(); //in Task
		
	Immediate maximum time
		public double needMaxWait(); //in Task
		public double wantMaxWait(); //in Task
		
	Immediate minimum amount
		public int framesNowWant(); //in AudStream
		public double wantMoreProgress(); //in Task
		public int framesNowNeed(); //in AudStream
		public double needMoreProgress(); //in Task
		public int framesNow(double importance); //in AudStream
		
	Some things can not give their total position, because there is a delay receiving that information, and the position is more when you get that information. Example: streaming over internet.
	
	2 types of timing: WITH TARGET SPEED AND UPDATE SIZE, and WITHOUT TARGET SPEED OR UPDATE SIZE.
	
	WITH TARGET SPEED AND UPDATE SIZE
		Define time as relative to sender and receiver separately.
			Data amount per frame, like "2 channels".
			Constant target updates per second.
			Constant target data amount per second.

	WITHOUT TARGET SPEED OR UPDATE SIZE
		Also, a type of stream etc that has no target updates or data per second.
			Data amount per frame, like "2 channels".

	BOTH TYPES: WITH TARGET SPEED AND UPDATE SIZE, and WITHOUT TARGET SPEED OR UPDATE SIZE.
		SENDER
			Time since received request to send.
			Data amount ready to send.
		RECEIVER
			Time since received data.	
			
	That complicates timing on the same computer. Define 2 types: LOCALTIMING and EXTERNALTIMING.
	
	LOCALTIMING
		Data amount per frame, like "2 channels".
		//Receiver pulls data from sender.
		//Sender keeps no statistics.
		2 types:
			WITHOUT TARGET SPEED OR UPDATE SIZE
			WITH TARGET SPEED AND UPDATE SIZE
				Constant target updates per second.
				Constant target data amount per second.
		//How to know when to do the next update?
			
	EXTERNALTIMING
		Data amount per frame, like "2 channels".
		Example: Streaming over internet.
		Sender and receiver keep statistics on the delay and progress of the stream.
	

	TIME QUEUE
		Exactly 1 time queue for the whole Audivolv running on 1 computer.
		Each Agent can schedule events, and must predict how long the event will take, and statistics are kept about each Agent.
		Scheduling an event requires this info:
			Target start time.
			Allowed standard deviation start time.
				If small, errors in start time are bad. If big, errors in start time are ok.
			Expected average duration.
			Expected standard deviation duration.
		Scheduling an event returns some estimate of chance it will start on time, std dev of start time, etc.
		Should a time queue be recursive, so child time queues could be rewarded/punished for accuracy of scheduling things?
		
	On the same computer, streams are delayed for similar reasons as streams across the internet.
		For example, streaming from a file or decompressing an mp3 takes a little time and the time it takes
			can vary like internet delays.
		A difference between local and internet streams is the local stream can be forced to start immediately,
			but its similar because it may block until it can run, like a file read blocks until the hard drive can read it.
		A local sender can estimate immediate-delay immediately, but an internet sender takes some delay (time to receive the response through the internet) to send you the estimate of immediate-delay.
		Maybe sender should never estimate immediate-delay.
		
	
	About "functionsThatIncreaseProgress": void run(double), void audStream(double[],int,int), and run(int,double[]):
		Should these be specific to whatever class uses them?
		These can be separate from measuring progress, target speed of progress, and how often progress should increase.
		
	When measuring total progress, double or long are not big enough to describe total progress of multiple computers.
		Should BigInteger be used instead?
		Java type long is big enough for 1 billion data units per second from each of 1 million computers
			working together for 2.5 hours. That is ok because a new stream can be created after 2 hours,
			and those sizes are more than enough to accomplish Audivolv's purpose for artificial-intelligence.
			
			
	<javaInterfacesToDefine>
		public interface TargetTiming{
			public double targetFreq();
			public double targetMinUpdateFreq();
		}
		public interface Progress{
			public long progress();
		}
	</javaInterfacesToDefine>

</timeDelayAndSync>